Sistemas de telecomunicaciones. Concepto de IP en las nuevas redes Integradas (página 2)
CAPITULO 2
2.- PROTOCOLO
H.323.
H.323 es el estándar creado por la Unión
Internacional de Telecomunicaciones (ITU) que se compone por un
protocolo sumamente complejo y extenso, el cual además de
incluir la voz sobre IP,
ofrece especificaciones para vídeo-conferencias y
aplicaciones en tiempo real,
entre otras variantes.
El H.323 es una familia de
estándares definidos por el ITU para las comunicaciones
multimedia sobre
redes LAN.
Está definido específicamente para
tecnologías LAN que no
garantizan una calidad de
servicio (QoS). Algunos ejemplos son TCP/IP e IPX
sobre Ethernet, Fast
Ethernet o Token Ring. La tecnología de
red más
común en la que se están implementando H.323 es
IP (Internet
Protocol).
2.1. COMPONENTES H.323.
Este estándar define un ámplio conjunto de
características y funciones.
Algunas son necesarias y otras opcionales. El H.323 define mucho
más que los terminales. El estándar define los
siguientes componente más relevantes como se muestra en la
siguiente figura:
- Entidad:
La especificación H.323 define el término
genérico entidad como cualquier componente que cumpla con
el estándar.
- Extremo:
Un extremo H.323 es un componente de la red que puede
enviar y recibir llamadas. Puede generar y/o recibir secuencias
de información.
- Terminal:
Un terminal H.323 es un extremo de la red que
proporciona comunicaciones bidireccionales en tiempo real con
otro terminal H.323, gateway o unidad de control
multipunto (MCU). Esta comunicación consta de señales
de control, indicaciones, audio, imagen en
color en
movimiento y
/o datos entre los
dos terminales. Conforme a la especificación, un terminal
H.323 puede proporcionar sólo voz, voz y datos, voz y
vídeo, o voz, datos y vídeo.
Las funciones de control que realizan los terminales son
las siguientes:
- H.245 para negociación del canal.
- H.225.0 (Q.931) para señalización y
control de llamada. - H.225.0 (RAS) para comunicación con el
gatekeeper.
También implementan los protocolos
RTP/RTCP para el manejo de los flujos de audio y video.
- Gatekeeper:
El gatekeeper (GK) es una entidad que proporciona la
traducción de direcciones y el control de
acceso a la red de los terminales H.323, gateways y MCUs. El GK
puede también ofrecer otros servicios a
los terminales, gateways y MCUs, tales como gestión
del ancho de banda y localización de los gateways o
pasarelas. El Gatekeeper realiza dos funciones de control de
llamadas que preservan la integridad de la red corporativa de
datos. La primera es la traslación de direcciones de los
terminales de la LAN a las correspondientes IP o IPX, tal y como
se describe en la especificación RAS. La segunda es la
gestión del ancho de banda, fijando el número de
conferencias que pueden estar dándose
simultáneamente en la LAN y rechazando las nuevas
peticiones por encima del nivel establecido, de manera tal que se
garantice ancho de banda suficiente para las aplicaciones de
datos sobre la LAN. El Gatekeeper proporciona todas las funciones
anteriores para los terminales, Gateways y MCUs, que están
registrados dentro de la denominada Zona de control
H.323.
Las funciones que debe desarrollar un gatekeeper son las
siguientes:
• Control de la
señalización.
• Control de acceso y administración de recursos,
autorización de llamadas.
• Traducción de direcciones de transporte
entre direcciones IP y alias.
• gestión del ancho de banda.
• gestión de llamadas(concesión de
permisos…)
• gestión del ancho de banda.
Para desarrollar estas funciones , entre el gatekeeper y
el endpoint se emplea el protocolo RAS (Registration /Admission
/Status) sobre UDP.
Un gatekeeper y sus endpoints definen una zona H.323, de
manera que en entornos LAN's es suficiente un gatekeeper, pero en
entornos como Internet, son necesarios varios de ellos, cada uno
definiendo una zona H.323.
Lógicamente, entre gatekeepers se
requerirá comunicación, por lo que actúa
como el punto central para todas las llamadas en una zona,
comportándose como un conmutador virtual.
Si bien el gatekeeper no es obligatorio, su empleo en un
entorno H.323 sí posibilita emplear más
eficientemente la plataforma, por ejemplo mediante el
enrutamiento de llamadas a su través.
Los gatekeepers son entidades funcionales separadas de
los endpoints H.323, pero es posible incluir funcionalidades
gatekeepers en los gateways y las MCU's.
- Gateway:
Un gateway H.323 (GW) es un extremo que proporciona
comunicaciones bidireccionales en tiempo real entre terminales
H.323 en la red IP y otros terminales o gateways en una red conmutada. En
general, el propósito del gateway es reflejar
transparentemente las características de un extremo en la
red IP a otro en una red conmutada y viceversa. los gateways, son
los sistemas
encargados de permitir que los equipos H.323 puedan operar con
otras redes.
Desarrollan la traducción de la
señalización, información de control e
información de usuario, posibilitando así
interoperabilidad entre redes, terminales y servicios, haciendo
viable la integración de servicios aún con
plataformas dispares, llámese PSTN y redes IP.
Una diferencia respecto a los gatekeepers, es que los
gateways sí cursan información de usuario,
soportada en RTP/UDP/IP.
- Funciones de los gateways:
- transcodificación de audio y
vídeo. - traducción de procedimientos de
comunicación. - traducción de formatos de
transmisión.
Evidentemente, dada su funcionalidad, los gateways son
elementos opcionales en entornos H.323, y sólo son
necesarios cuando se requiere una interconexión entre
entornos H.323 y entornos no H.323:
- MCU (Multipoint Control Units):
La Unidad de Control Multipunto está
diseñada para soportar la conferencia entre
tres o más puntos, bajo el estándar H.323, llevando
la negociación entre terminales para determinar las
capacidades comunes para el proceso de
audio y vídeo y controlar la
multidifusión.
La comunicación bajo H.323 contempla las
señales de audio y vídeo. La señal de audio
se digitaliza y se comprime bajo uno de los algoritmos
soportados, tales como el G.711 o G.723, y la señal de
vídeo (opcional) se trata con la norma H.261 o H.263. Los
datos (opcional) se manejan bajo el estándar T.120 que
permite la compartición de aplicaciones en conferencias
punto a punto y multipunto.
Dado el jitter, que sufren los paquetes IP en la red, y
las consecuencias negativas de esto para el tráfico de
audio y vídeo, en el terminal H.323 se requiere un buffer
de recepción para absorber, en la medida de lo posible,
estas fluctuaciones en la demora de los paquetes IP, anulando o
reduciendo el efecto negativo que el jitter puede producir en
flujos de información de usuario con requerimientos de
tiempo real.
Los protocolos de control comprendidos en H.323, unos se
encapsulan en UDP (protocolos H.225.0 (RAS, Registration
Admisión Status), que se desarrolla entre el gatekeeper y
los endpoints) y otros en TCP (H.225.0 (Q.931), para el control
de la llamada y H.245 para el control del canal.
2.2. FLUJO DE LLAMADAS.
El establecimiento de la llamada en H.323 se lleva a
cabo en tres fases:
- Fase RAS: intercambio de mensajes entre el gatekeeper
y el endpoint., para la traducción de direcciones ,
autorización de llamadas y gestión del ancho de
banda. - Fase Q.931: intercambio de mensajes entre endpoints
para el establecimiento de conexiones
lógicas. - Fase H.245: intercambio de mensajes entre endpoints
para acordar en intercambio de información de
usuario.
Dependiendo del papel que juegue el gatekeeper en las
llamadas H.323 podremos hablar de dos modelos:
- modelo de llamada H.323 directa (direct routed
model) - modelo de llamada H.323 indirecta (gatekker routed
model)
A continuación de estas tres fases de
establecimiento de llamada, se lleva a cabo la transferencia de
información de usuario por medio de los protocolos
RTP/RTCP, según lo acordado en la fase H.245, previa
apertura de los canales lógicos en los endpoints. Estos
canales lógicos son unidireccionales, por lo que para una
comunicación bidireccional se requiere abrir uno en cada
dirección de transmisión. En la
transferencia de medios no
interviene el gatekeeper, pues es solo una entidad de
señalización, sino que se lleva a cabo directamente
entre os endpoints.
Hasta la fecha, el estandar H.323 ha evolucionado desde
la primera versión H.323v1, hasta la última
versión H323v4, mejorando la primera versión en
cuestiones como seguridad,
servicios suplementarios, identificación de llamadas,
conexión rápida……etc.
2.3. CARACTERISTICAS Y RECOMENDACIONES DEL PROTOCOLO
H.323
El estándar H.323 especifica los componentes,
protocolos y procedimientos que proveen los servicios de
comunicación multimedia sobre redes de paquetes sin
garantía de calidad de
servicio,
tanto para sesiones multipunto como punto a punto. La
tecnología de red más común en la que se
están implementando H.323 es IP (Internet Protocol).
Además, H.323 también define la
señalización necesaria para comunicaciones
multimedia sobre redes IP (entre otras). Para el transporte de
medios utiliza los protocolos RTP/RTCP.Los terminales y equipos
H.323 soportan aplicaciones con requerimientos de tiempo real
(voz y vídeo), así como aplicaciones de datos y
combinaciones de ellas (videotelefonía, etc). Los
terminales H.323 pueden ser terminales explícitamente
diseñados a este fin o pueden estar integrados en
PC's.
El estándar H.323 incluye entre otras las
siguientes recomendaciones:
- H.225.0: paquetización,
sincronización y
señalización. - H.245: control del canal.
- G.711, G.722, G.723.1, G.728, G.729: codificación audio.
- Además también define recomendaciones
sobre conferencias de datos en tiempo real y
seguridad.
H.323 define una serie de entidades en una red H.323 con
una serie de funcionalidades:
- Direccionamiento:
- RAS (Registration, Admision and Status).
Protocolo de comunicaciones que permite a una estación
H.323 localizar otra estación H.323 a través del
Gatekeeper. - DNS (Domain Name Service). Servicio de
resolución de nombres en direcciones IP con el mismo fin
que el protocolo RAS pero a través de un servidor
DNS.
- Señalización:
1. Q.931
Señalización inicial de
llamada
2. H.225 Control de llamada:
señalización, registro y
admisión, y paquetización / sincronización
del stream (flujo) de voz
3. H.245 Protocolo de
control para especificar mensajes de apertura y cierre de
canales para streams de voz
- Compresión de
voz:
1. Requerido:
G.711
2. Opcionales: G.728, G.729
y G.723
- Transmisión de
voz:
1. UDP. La
transmisión se realiza sobre paquetes UDP, pues aunque
UDP no ofrece integridad en los datos, el aprovechamiento del
ancho de banda es mayor que con TCP. UDP
provee a los usuarios acceso a los servicios IP. Los
paquetes UDP son entregados como paquetes IP no orientados a
conexión, los cuales pueden ser descartados antes de
alcanzar su objetivo.
2. RTP (Real Time Protocol).
Maneja los aspectos relativos a la temporización,
marcando los paquetes UDP con la información necesaria
para la correcta entrega de los mismos en
recepción.
- Control de la
transmisión:
1. RTCP (Real Time Control
Protocol). Se utiliza principalmente para detectar situaciones
de congestión de la red y tomar, en su caso, acciones
correctoras. Actualmente se puede partir de
una serie de elementos ya disponibles en el mercado y
que, según diferentes diseños, permitirán
construir las aplicaciones VoIP. Estos
elementos son:
- Teléfonos IP.
- Adaptadores para PC.
- Hubs telefónicos.
- Gateways (pasarelas RTC / IP).
- Gatekeeper.
- Unidades de audioconferencia múltiple. (MCU
voz) - Servicios de directorio.
2.4. ARQUITECTURA DEL
PROTOCOLO H.323.
En una arquitectura H.323 (como la que se muestra en la
Figura 1) se integran como componentes básicos los
Terminales, Gateways (para interconexión con resursos
PSTN/IN), Gatekeepers (Control de admisión, registro y
ancho de banda) y MCUs (Multiconference Control
Units).
Dentro de H.323 se incluyen todo un conjunto de
protocolos perfectamente integrados (en la Figura 2 se ilustra la
pila de protocolos H.323) que toman parte en el establecimiento y
mantenimiento
de conferencias multimedia: Q.931 para el establecimiento de
llamada, H.225 para la señalización, H.245 para la
negociación de capacidades y el establecimiento de
canales, H.450.x para la definición de servicios
suplementarios (Call Park, Call Pickup, Call Hold, Call Transfer,
Call Diversion, MWI, …), RAS para el registro de terminales y
el control de admisión, RTP/RTCP para el transporte y
secuenciación de los flujos multimedia, G.711/G.712 para
la especificación de los codecs, T.120 para
colaboración y "dataconferencia"… Esto da una idea muy
clara de una de las características menos agradables de
este protocolo, y que siempre han argumentado sus detractores: su
excesiva complejidad, frente a la sencillez del modelo
Internet en que se basa SIP. De hecho SIP se podría
comparar, grosso modo, con las partes de Q.931 y H.225 de
H.323.
Figura 1
Figura 2
2.5. DEFINICIÒN DE PROTOCOLO
SIP.
El protocolo "Session Initiation Protocol" (SIP) es un
estándar emergente para establecer, enrutar y modificar
sesiones de comunicaciones a través de redes Internet
Protocol (IP). Utiliza el modelo de Internet y lo convierte al
mundo de las telecomunicaciones, utilizando protocolos Internet
existentes tales como HTTP y SMTP
(Simple Mail Transfer Protocol). También usa una estructura de
dirección URL. Usa estas direcciones de tipo correo
electrónico para identificar a los usuarios en lugar
de los dispositivos que los utilizan. De esta forma SIP no
depende del dispositivo y no hace distinción alguna entre
voz y datos, teléfono u ordenador. Como se
describe a continuación, SIP es usado mas para el manejo
de servicios, mientras que H.323 se usa prácticamente para
la conversión del número telefónico en
paquetes IP.
2.6. CARACTERÍSTICAS BÁSICAS DEL
PROTOCOLO SIP.
Se trata de un protocolo para el establecimiento de
sesiones sobre una red IP. Una sesión que puede soportar
desde una llamada telefónica hasta una multiconferencia
multimedia con elementos de colaboaración. Está
siendo desarrollado por el SIPWG del IETF (RFC 2543, 2543bis),
con la misma filosofía de sencillez y mínimo
esfuerzo de siempre. SIP está pensado como un mecanismo
para el establecimiento, la terminación y la
modificación de sesiones. Se trata de un protocolo basado
en el paradigma de
petición/respuesta (request-response), al igual que HTTP o
SMTP.
SIP maneja mensajes de petición: [que se
estructuran en tres bloques] Request Line + Cabecera + Cuerpo, y
mensajes de respuesta: Status Line + Cabecera + Cuerpo. En ambos
casos el cuerpo es independiente de SIP y puede contener
cualquier cosa. A efectos de estandarización se definen
métodos
para describir las áreas de especificación; SIP
define los siguientes métodos: invite, bye, options, ack,
register, cancel, info (rfc 2976), comet, prack, subscribe/,
notify/, message.
En la Figura 3 se ilustra un mensaje tipo, con los
campos más importantes de la cabecera y el cuerpo rellenos
de forma genérica.
Figura 3
Las respuestas son del tipo HTTP:
1xx Informational (100 Trying, 180 Ringing, 181 Call
is being forwarded)
2xx Successful (200 OK, 202 Accepted )
3xx Redirection (300 Multiple choices, 301 Moved
Permanently, 302 Moved Temporarily)
4xx Client Error (400 Bad Request, 404 Not Found,
482 Loop Detected, 486 Busy here)
5xx Server Failure (500 Server Internal Error, 501
Not Implemented)
6xx Global Failure (600 Busy Everywhere, 603
Decline).
SIP se puede definir como un protocolo de control,
pensado para la creación, modificación y
terminación de sesiones, con uno o más
participantes. Esas sesiones pueden comprender conferencias
multimedia, llamadas telefónicas sobre Internet (o
cualquier otra red IP), distribución de contenidos multimedia…
Las sesiones pueden realizarse en multicast o en unicast; los
participantes pueden negociar los contenidos y capacidades que
van a utilizar; soporta movilidad de los usuarios, mediante
utilización de proxies.
Las funcionalidades que se le exigen a un protocolo de
estas características, son básicamente: La
traducción de nombres y las ubicación de usuarios,
la negociación de capacidades de cada usuario, la
gestión de los usuarios que toman parte en una conferencia
(sesión) y la gestión de los cambios en las
capacidades de cada participante.
SIP propone la utilización de un direccionamiento
análogo al que se usa para el servicio de correo
electrónico (e.g. sip:paco[arroba]bbva.com). Para la
descripción de contenidos, puede utilizar
MIME, estándar de facto en Internet; aunque el IETF
sugiere, para la descripción de la propia sesión,
la utilización de SDP (Session Description Protocol), que
no es un protocolo propiamente dicho, sino un formato [de
texto plano]
para describir los flujos multimedia que se intercambian en una
sesión.
Al igual que el servicio de correo, utiliza DNS para
encontrar el servidor adecuado al que se le debe pasar una
determinada petición. Está pensado para ser
independiente de los niveles inferiores; sólo necesita un
servicio de datagramas no fiable, con lo cual se puede montar
sobre UDP o TCP. Sobre ese servicio no fiable se monta un
transporte con RTP/RTCP.
La Figura 4 pretende ponernos un poco en
situación, representando los protocolos implicados en los
aspectos de señalización (H.323, SIP, RTCP),
provisión de calidad de servicio (RTCP, RSVP), transporte
y encapsulación de contenidos multimedia y/o de medios
múltiples (H.261, MPEG/RTP) que
aparecen en escena cuando se aborda el problema del
establecimiento, control y transporte de sesiones, que soportan
comunicaciones multimedia entre varios participantes.
Figura 4
2.7. ARQUITECTURA DEL PROTOCOLO SIP.
SIP necesita dos componentes básicos: un agente
de usuario (UA, User Agent) y un servidor (NS, Network Server).
El agente de usuario, comprende un elemento cliente (UAC,
User Agent Client) y un elemento servidor (UAS, User Agent
Server). El cliente inicia las llamadas, y el servidor las
responde: la idea es realizar llamadas (establecer sesiones
‘peer-to-peer’, P2P) con un protocolo
Cliente/Servidor.
Las funciones principales de los servidores SIP
son la resolución de nombres y la ubicación de
usuarios. Se comunican con otros servidores pasándose
mensajes en base a protocolos NHR. Los servidores pueden guardar
o no información de estado, dando
lugar a dos modos de funcionamiento (‘statefull’ o
‘stateless’ respectivamente para los anglosajones).
Los servidores sin estado constituirían lo que se
podría denominar el ‘backbone’ de una
infraestructura SIP, mientras que los servidores con estado
serían los dispositivos más cercanos alos agentes
de usuario, que se encargarían del control de los dominios
de usuarios.
Otras funcionalidades importantes de los servidores son
la redirección (de una petición) y la
"distribución" (pueden pasar una llamada a un grupo de
usuarios, apropiándose de la sesión el primero que
conteste).
Con esos componentes, UAC, UAS y NS, se puede montar una
infraestructura básica de SIP; sobre la cual se pueden
montar servidores de aplicaciones que podrían alojar
módulos de servicio: de mensajería
instantánea, de presencia, de control de llamada, perfiles
de usuario… Al mismo nivel se supone que
interaccionarían con otros servidores de contenidos en una
arquitectura distribuida que integraría el balanceo de
carga y soportaría la interfaz de
gestión.
En el Diagrama 1 se
pretende ilustrar el establecimiento de una llamada para mostrar
cómo interactúan los elementos básicos que
hemos mencionado más arriba.
En este ejemplo, el usuario
quiere hablar con
es decir con un usuario que habitualmente está en su
mismo dominio; pero por
algún motivo, que desconocemos, hoy no está en
bbva.com, sino en bbv.es aunque paco no lo sabe: tal es
así que manda una invitación (invocará un
método
INVITE) para el usuario
al servidor responsable de su dominio (en este caso es un
servidor proxy con estado,
‘Stateful Proxy 1’). El servidor enviará la
invitación a un servidor para de redirección para
tratar de averigüar la localización actual de emilio.
Es este servidor de redirección el que determina que el
usuario emilio está en el dominio bbv.es y le contesta al
proxy con un 302 MOVED TEMPORARILY que incluye la nueva
dirección de emilio(sip:).
El proxy responde con un 302 ACK, puesto que aquí termina
la secuencia de la invitación inicial (INVITE(1) de la
figura).
A partir de esta situación, el Proxy 1 [con
estado] (Stateful Proxy 1) podría mandarle la
dirección de emilio a paco para que él tratara de
comunicarse con ´directamente con sip:emilio[arroba]bbv.es.
En el ejemplo, lo que hace el proxy 1 es modificar la
invitación y tratar de encontrar a
sip:emilio[arroba]bbv.es. Como no conoce a ningún otro
servidor con estado que se responsabilice del dominio bbv.es,
pasará la invitación a un servidor sin estado
(‘Stateless proxy’) que conocerá el siguiente
salto que debe seguir para llegar hasta
sip:emilio[arroba]bbv.es.
Para simplificar el ejemplo hemos querido que ese primer
proxy sin estado conozca a un servidor proxy que controla el
dominio bbv.es (‘Stateful Proxy 2’). Ese segundo
proxy completa la entrega de la invitación para
sip:emilio[arroba]bbv.es; momento en el cual emilio acepta la
llamada enviando un mensaje de respuesta (200 OK), que recorre el
mismo camino de vuelta de la invitación hasta llegar a
sip:paco[arroba]bbva.com. Ahora paco debería mandarle un
ACK de esta respuesta a emilio; y aunque en principio
podría hacerlo directamente, en nuestro ejemplo hemos
decidido que toda la señalización pase por los
proxies de cada dominio (se supone que así lo
habrán indicado en los mensajes de invitación que
se han cruzado).
SIP sigue el modelo Cliente/Servidor: los proveedores de
servicio [de acceso troncal] podrían ofrecer esa
infraestructura SIP como un servicio IP más a otros
proveedores de servicio, que a su vez podrían montar sobre
ella sus propios servicios SIP que comercializarían en
modo ISP/ASP.
SIP proporciona los mecanismos necesarios para ofrecer
una serie de servicios:
Usuarios:
- Localización.
- Disponibilidad y capacidades (servicio de presencia y
terminal asociado). - Perfil.
Llamadas
- Establecimiento.
- Mantenimiento.
- Desvíos.
- Traducción de direcciones.
- Entrega de los números llamado y
llamante. - Movilidad: direccionamiento único
independiente de la ubicación del usuario. - Negociación del tipo de termina.l
- Negociación de las capacidades del
terminal. - Autenticación de usuarios llamado y
llamante. - Tranferencias ciegas y supervisadas.
- Incorporación a conferencias
multicast.
SIP mecanismos necesarios para ofrecer una serie de
servicios según se puede ver en la figura 5:
Figura 5
2.8. MENSAJERÍA INSTANTÁNEA (IM) DEL
SIP.
La mensajería instantánea puede que
merezca un apartado aparte, puesto que se ha convertido, por su
sencillez e inmediatez, en un medio de comunicación que
resulta adecuado para el intercambio rápido de ideas entre
pequeños equipos de
trabajo distribuidos. El concepto de la
"lista de amiguetes" (‘buddy list’) que ha surgido en
entornos de IM como AOL o ICQ resulta interesante: es el hecho de
poder disponer
de una lista de usuarios de un servicio, con su disponibilidad
online anunciada constantemente en la red. Es un servicio que se
integra fácilmente, puesto que se trata de clientes muy
ligeros.
AOL y Yahoo han conseguido congregar una gran comunidad de
usuarios en entornos corporativos (¿Quién no se ha
pasado la mitad de la jornada mandándose mensajitos con
sus colegas en el Yahoo Messanger?). Lotus y Microsoft (M$)
están integrando servidores de IM en sus plataformas
corporativas; e incluso es una funcionalidad que se está
integrando en muchas plataformas CRM, como un
canal más de contacto con el cliente.
Una sesión que se establece con SIP puede incluir
cualquier medio de soporte, de manera que podemos pasar una
comunicación vía IM a una conferencia
telefónica, una pizarra compartida tipo NetMeeting o una
videoconferencia. Podemos pensar en una especie de "telefonía instantánea" como evolución.
En el mundillo de la telefonía móvil hay
un claro precedente de la IM: el servicio de SMS. Tanto Yahoo
como AOL han visto la potencialidad de este servicio y ya se
están moviendo para alcanzar acuerdos con proveedores de
servicios móviles.
Ese concepto de presencia asociado a las ‘buddy
lists’ también está evolucionando; se habla
de presencia no sólo a nivel del propio PC del puesto,
sino asociado con cualquier tipo de dispositivo o
aplicación independiente: es el caso de los
‘bots’ que IBM utiliza en su Lotus SameTime: son
‘buddy lists’ que representan realmente consultas a
bases de datos
o directorios corporativos. En principio se trata de la
extensión del concepto de mensajería
instantánea a un contexto mucho más amplio del que
propició su origen: estamos hablando del intercambio de
mensajes entre usuarios, que pueden ser personas (usuarios
finales del servicio que tendrán uno u otro perfil
asociado), máquinas
(cualquier tipo de terminal asociado a un usuario), o
aplicaciones (que pueden incluir agentes inteligentes o servicios
Web).
Todas las posibilidades que se han mencionado nos llevan
a la integración de todo tipo de comunicación en el
"escritorio" del puesto de cada empleado, posibilitando la
gestión conjunta de todos los medios de
comunicación a disposición de aquellos, con un
‘repositorio’ único de contactos a mantener.
Este aspecto resulta de un interés
indudable en el entorno empresarial, puesto que redunda de forma
directa en el incremento de la productividad de
los empleados, permitiendo el despliegue de servicios de valor
añadido como cualquier otro servicio sobre una
arquitectura SIP apoyada en una red IP multiservicio.
A pesar del ámbito de este documento, no debemos
olvidar que, la que en boca de muchos es la ‘killer
application’ que servirá de catalizador para los
servicios de banda ancha en
el acceso, los juegos en red,
se beneficia enormemente de las posibilidades que ofrece SIP. Una
sesión de juego en red
(‘online gaming’) es una comunicación sobre
UDP que se establece entre sockets seguros, durante
la cual se intercambian flujos multimedia RTP. Además hoy
en día ya se incorporan servicios de IM para la
comunicación y coordinación táctica de los
jugadores. SIP va a permitir evolucionar hacia un escenario de
mayor interactividad con comunicación vía VoIP
entre los jugadores; de la misma forma el servicio de presencia
permitirá evitar la necesidad de conectarse con un
servidor maestro para iniciar las partidas, pudiendo utilizar una
lista para ver quién está conectado en cada momento
e invitarle a una partida sobre la marcha.
2.9. PROTOCOLO H.248 ( MEGACO).
Este protocolo se define en la Recomendación
H.248 de la ITU-T. El protocolo H.248 o Megaco permite la
conmutación de llamadas de voz, fax y
multimedia entre la red PSTN y las redes IP de siguiente
generación. El protocolo Megaco, que tiene su origen en el
protocolo MGCP (Media Gateway Control Protocol, Protocolo de
control de puerta de enlace al medio), proporciona un control
centralizado de las comunicaciones y servicios multimedia a
través de redes basadas en IP. Megaco está
adquiriendo solidez en el mercado porque permite una mayor
escalabilidad que H.323, y da respuesta a las necesidades
técnicas y a las funciones de conferencia
multimedia que se pasaron por alto en el protocolo
MGCP.
Funcionalmente, Megaco es un protocolo de
señalización utilizado entre los elementos de una
arquitectura distribuida que incluye media gateway y
controladores de media gateway (conocidos a menudo como
softswitches, gatekeeper o call server)
H.248 es el resultado de la cooperación entre
la ITU
y el IETF. Antes de
lograr esta cooperación existían varios protocolos
similares compitiendo entre si, principalmente MGCP (la
combinación de SGCP e IPDC) y MDCP. H.248 se
considera un protocolo complementario a H.323 y SIP, ya que un
Media Gateway Controller (MGC), controlará varios Media
Gateways utilizando H.248, pero será capaz de comunicarse
con otro MGC utilizando H.323 o SIP.
2.9.1. MGCP.
El MGCP es, en esencia, un protocolo maestro/esclavo,
donde se espera que los gateways ejecuten comandos enviados
por el MGC. El Protocolo de Control de Media Gateway (MGCP) es
usado para controlar los gateways de telefonía desde los
elementos de control de llamadas externos llamados Media Gateways
Controllers (MGC) o Gatekeepers.
Un gateway de telefonía es un elemento de red que
provee conversión entre las señales de audio
transportadas sobre los circuitos
telefónicos y los paquetes de datos transportados sobre la
internet o sobre otra red de paquetes.
MGCP asume una arquitectura de control de llamada, donde
la inteligencia
del control de la llamada está fuera de los gateways y
manejada por un elemento de control de llamada externo. El
MGCP asume que estos elementos de control de llamadas o MGC, se
sincronizarán entre sí para enviar comandos
coherentemente a los gateways que están bajo su
control.
Lo que se propuso con MGCP fue sacar el control de la
señalización del propio gateway (GW),
llevándolo a otro elemento, el ‘media gateway
controller’ MGC (que se conoce como
‘softswitch’) que se encargará del control de
los media gateways’(MGW).
A nivel de sistemas lo que se ha hecho es desagregar el
gatekeeper (GK) en sus equivalentes en el mundo SS7. Esta
iniciativa surgió de varios fabricantes con el nombre de
IPDC (Cisco, Alcatel, 3Com et al.) por un lado y SGCP (Telcordia)
por otro; un esfuerzo que el IETF aglutinó bajo la
denominación de MGCP y asignada a la responsabilidad del grupo de trabajo
Megaco. MGCP es en la fecha de redacción de este documento un documento de
trabajo. Tanto IETF como la ITU-T trabajan para llegar a un
estándar, el primero bajo la responsabilidad de Megaco y
como H.248 para el segundo.
En MGCP se puede decir que se ha separado la
"inteligencia" (las funciones de control) de los datos (los
contenidos: ‘the media’). Que se trata de un protoclo
Maestro/Esclavo. El maestro es el MGC (‘softswitch’ o
‘call agent’) y el esclavo es el MGW (que puede ser
un GW de VoIP, un DSLAM, un router MPLS,
un teléfono IP,…). Esta es precisamente la
característica que más choca con la
filosofía (P2P) de SIP. Otra característica
interesante es que intenta reproducir el modelo de la PSTN/IN
sobre IP (en la Figura 6 se ilustra el escenario típico
para un despliegue tipo ‘Internet Telephony’ que es
la aplicación para la que se pensó, al menos en
principio esta solución), en contra del modelo distribuido
que propone SIP.
Figura 6
El Megaco pretende dar una solución basada en una
visión propia de las Telcos tradicionales, una oficina central
(Central Office, CO, en
este caso IPCO) y una red de sucursales (Branch Offices, BO). Tal
y como se observa en la Figura 7, SIP puede complementar a MGCP
en un escenario donde tengamos varios MGC.
Figura 7
En la Figura 8 se detalla un poco más lo que
sería un escenario integrado con la PSTN, pensando en
prestar el servicio de telefonía sobre
Internet.
Figura 8
Un tema de debate
importante es la utilización de MGCP para controlar los
terminales (los teléfonos IP por ejemplo); el problema que
surge es que sólo soporta servicios básicos de red
inteligente. El tema es que si se quieren desplegar servicios
avanzados necesitamos montar SIP tanto en los terminales como
sobre la red de señalización, realizando las
funciones de control asociadas al servicio.
Ya se ha comentado más arriba que la
visión de los partidarios de MGCP es que la inteligencia
del servicio esté pegada a los MGC (softswitch), y de
hecho en el corto plazo es un planteamiento adecuado puesto que
el esfuerzo de convergencia se centrará en los puntos de
interconexión entre la PSTN y la red IP, y pro tanto
interesará que los servidores SIP estén junto a los
MGC en la CO. Pero, según avancemos hacia un escenario
más integrado, la atención se centrará en la
infraestructura IP, con lo cual la función de
los MGC se alejará de los puntos de interconexión.
Finalmente, en un entorno IP puro, la función de
creación de servicios se distribuirá por toda la
red: se puede extender el modelo ASP para dar servicios de
voz.
Tanto los ASPs como los ISPs, o incluso los propios
usuarios finales pueden crear sus propios servicios. Se puede
pensar en un escenario basado en SIP, donde se utilice MGCP para
controlar internamente un GW de Telefonía IP (TIP) y los
servidores de aplicaciones SIP distribuirían servicios por
la red a través de los servidores proxy SIP.
Como conclusión debemos extraer el hecho de que
MGCP no se puede considerar como un competidor de SIP, puesto que
ambos resultan complementarios en ciertos aspectos, mientras que
son mutuamente excluyentes en otros.
Esta idea de dividir el Gateway de voz en varias
entidades funcionales se ha propuesto también desde
iniciativas como TIPHON (Telecommunications and Internet Protocol
Harmonization Over Networks) de la ETSI, con la intención
de proporcionar una arquitectura "escalable" que soporte el
servicio de Telefonía IP con la necesaria capacidad para
convivir con las redes tradicionales de conmutación de
circuitos (SCN, Switched Circuit Networks) como la PSTN. Esta
división es la que se ilustra en el Diagrama 2 (de la
misma forma en la Figura 9 podemos ver los componentes e
interfaces en cuya definición trabaja la ETSI en el
ámbito de TIPHON).
Figura 9
2.10. SIGTRAN.
2.10.1 ¿QUÉ ES EL SIGTRAN
?
SIGTRAN (de signalling transport) es el nombre del grupo
de trabajo del IETF encargado de definir una arquitectura para el
transporte de señalización en tiempo real sobre
redes IP. A raíz de ello, no sólo se creó
una arquitectura, sino que se definió un conjunto de
protocolos de comunicaciones para transportar mensajes SS7 sobre
IP.
2.10.2 ARQUITECTURA DE LOS PROTOCOLOS SIGTRAN
.
La arquitectura definida por el Sigtran [RFC2719] consta
de tres componentes:
• IP estándar como protocolo de
red.
• Un protocolo común de transporte de
señalización. Los protocolos definidos por el
Sigtran se basan en un nuevo protocolo de transporte sobre IP,
llamado SCTP (Stream Control Transmission Protocol).
• Capas de adaptación específicas
para cada capa de la torre SS7 que se necesite transportar. El
IETF ha definido las siguientes: M2PA, M2UA, M3UA, SUA, TUA e
IUA. IP SCTP Capa de adaptación S7UP/S7AP
- M2UA [RFC 3331].
M2UA son las siglas de MTP2 User Adaptation. El
protocolo M2UA, al igual que M2PA, adapta MTP3 a SCTP, e
igualmente gestiona asociaciones SCTP en lugar de enlaces MTP3.
M2UA permite el intercambio de mensajes MTP3 entre dos puntos de
señalización IP o entre un punto de
señalización IP y una pasarela IP-SS7.
M2UA es un protocolo entre pares en caso de que la
comunicación comience y
termine en dos puntos de señalización IP,
sin SGWs intermedios, tal como muestra la
Figura 12.
Sin embargo, M2UA no es un protocolo entre pares si se
implementa en una pasarela de señalización. En ese
caso, M2UA no procesa las órdenes (primitivas del
protocolo) que le llegan desde la capa superior (MTP3), sino que
las envía tal cual hacia un nodo remoto, mediante
SCTP.
Como M2UA no procesa las primitivas de MTP3, sino que
las reenvía, en caso de que se utilice un SGW se debe
entender este protocolo como un medio que comunica la capa MTP3
de un nodo IP con la capa MTP2 de un SGW, tal como muestra la
Figura 13.
De esta forma, varios puntos de
señalización IP con MTP3 sobre M2UA pueden acceder
a la red SS7 tradicional a través de los mismos enlaces
MTP2 físicos.
Es importante tener en cuenta que, debido a la propia
naturaleza del
protocolo, sólo puede existir un SGW M2UA en una misma
comunicación MTP3, por lo que no se puede utilizar para
transportar mensajes MTP3 entre dos nodos SS7 puros a
través de una red IP. Si se utiliza M2UA, alguno de los
extremos es un punto de señalización IP.
- M3UA [RFC 3332].
M3UA son las siglas de MTP3-User Adaptation. M3UA es un
protocolo que
transporta mensajes procedentes de un usuario de MTP3
(ISUP, TUP o SCCP) a través de una red SCTP/IP hasta un
nodo remoto.
De forma similar a M2UA, M3UA simplemente transporta los
mensajes hasta el destino, pero no realiza por sí mismo
las funciones de la capa MTP3. Esto significa que M3UA no dispone
de tablas de encaminamiento basadas en puntos de
señalización, ni realiza ninguna otra
función propia de MTP3.
En general, M3UA se utilizará como medio de
transporte de primitivas entre la capa usuaria de MTP-3 (SCCP o
ISUP) de un punto de señalización IP y la capa MTP3
de un SGW remoto, tal como muestra la Figura 14.
- UTILIZACIÓN DE M3UA.
Como se ha visto, dado que M3UA transporta primitivas
desde la capa ISUP o SCCP de un nodo hasta la capa MTP3 de otro
(típicamente un SGW), este protocolo sólo puede
utilizarse para conectar nodos con señalización IP
a una red SS7. Por tanto, no se puede utilizar M3UA para
descargar tráfico SS7 entre dos nodos TDM a través
de red IP, a no ser que se utilicen SGWs con SCCP. Pero para esta
aplicación es mucho más adecuado utilizar SGWs con
M2PA, por los motivos indicados en el apartado 3.3.
 Página anterior | Volver al principio del trabajo | Página siguiente  |